NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/4448

Text File | 1996-08-05 | 3.4 KB | 79 lines

Newsgroups: comp.sys.amiga.programmer
Path: mozart.unx.sas.com!walker
From: [e-mail] (Doug Walker)
Subject: Re: 3 bugs in SAS/C v. 6.56
Originator: [e-mail]
Sender: [e-mail] (Noter of Newsworthy Events)
Message-ID: <[e-mail]>
Date: Thu, 29 Feb 1996 13:02:24 GMT
X-Nntp-Posting-Host: chang.unx.sas.com
References: <4gjvvc$[e-mail]> <[e-mail]>
Organization: SAS Institute Inc.


In article <[e-mail]>, Morten B=?iso-8859-2?Q?=F8geskov Jensen <[e-mail]>?= writes:
|> However I belive that ">" and other boolean operations are
|> left-associative (I know), as so they take the type of the 2nd (right)
|> parameter, and since 0x7fff per default is signed, there is an implicit
|> type conversion of unsigned short to signed short. this is most
|> unfortunate, however this is the way most C-compilers work.

This is not correct.  Binary operators in C do not simply take the type
of the right parameter.  The reality is a little more complicated.

To start off with, both operands are subjected to the "usual arithmetic
conversions", described in section 3.2.1.5 of the ANSI standard.  These
basically boil down to the fact that operands of binary operators are
promoted to the "longer" of the two types involved, but they are always
promoted to at least type "int".  Type "length" is basically

    long double
    double
    float
    unsigned long
    long/unsigned int
    int

If an operand's type is char, unsigned char, signed char, short, or
unsigned short, it will be promoted to the "shortest" item in the
preceding list that will hold all the possible values associated
with its type.

Once both operands have been promoted according to the table, the types
of each operand are examined.  If one is longer than the other,
according to the table, the shorter operand is promoted to the longer
type.

There is an ambiguity at long/unsigned int: if integers are four bytes, a
long will not represent all possible values stored in an unsigned int, so
if one parameter to an operation is long and the other unsigned int, both
operands must be converted to unsigned long.  If integers are two bytes,
this is not a problem and the unsigned int is converted to long.

In this particular case, the two unsigned short parameters to the | operator
will be converted to int since long integers are being used.  This should be
OK, since their values should be translated without sign-extending because
they are unsigned.  This should result in an integer with value 0x0000ffff.
The comparison now takes an int on the left (result of the | operation) and
an int on the right, so its result is int.

If integers were two bytes for this program instead of one, the unsigned shorts
would get promoted to unsigned int, and the result of the | operation would be
unsigned int.  The 0x7fff on the right of the > would be promoted to unsigned
int, and the comparison should still work.

Your proposed fix, casting the right side to (unsigned short), does nothing in
either case since the unsigned short parm would be immediately promoted to
either int or unsigned int, depending on the length of an int.



--
  *****                    / [e-mail]
 *|_o_o|\\     Doug Walker<  BIX, Portal: djwalker
 *|. o.| ||                \ AOL: weissblau
  | o  |//
  ======
Any opinions expressed are mine, not those of SAS Institute, Inc.